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Abstract 


This document describes the use of the DES Cipher algorithm in Cipher 
Block Chaining Mode, with an explicit IV, as a confidentiality 
mechanism within the context of the IPSec Encapsulating Security 
Payload (ESP). 


1. Introduction 


This document describes the use of the DES Cipher algorithm in Cipher 
Block Chaining Mode as a confidentiality mechanism within the context 
of the Encapsulating Security Payload. 


DES is a symmetric block cipher algorithm. The algorithm is described 
in [FIPS-46-2] [FIPS-74] [FIPS-81]. [Schneier96] provides a general 
description of Cipher Block Chaining Mode, a mode which is applicable 
to several encryption algorithms. 


As specified in this memo, DES-CBC is not an authentication 
mechanism. [Although DES-MAC, described in [Schneier96] amongst other 


places, does provide authentication, DES-MAC is not discussed here. ] 


For further information on how the various pieces of ESP fit together 
to provide security services, refer to [ESP] and [road]. 
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The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC-2119]. 


2. Algorithm and Mode 


DES-CBC is a symmetric secret-key block algorithm. It has a block 
size of 64 bits. 


[FIPS-46-2] [FIPS-74] and [FIPS-81] describe the DES algorithm, while 
[Schneier96] provides a good description of CBC mode. 


2.1 Performance 


Phil Karn has tuned DES-CBC software to achieve 10.45 Mbps with a 90 
MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pentium. Other DES 
speed estimates may be found in [Schneier96]. 


3. ESP Payload 
DES-CBC requires an explicit Initialization Vector (IV) of 8 octets 


(64 bits). This IV immediately precedes the protected (encrypted) 
payload. The IV MUST be a random value. 


Including the IV in each datagram ensures that decryption of each 
received datagram can be performed, even when some datagrams are 
dropped, or datagrams are re-ordered in transit. 


Implementation note: 


Common practice is to use random data for the first IV and the 
last 8 octets of encrypted data from an encryption process as the 
IV for the next encryption process; this logically extends the CBC 
across the packets. It also has the advantage of limiting the 
leakage of information from the random number genrator. No matter 
which mechnism is used, the receiver MUST NOT assume any meaning 
for this value, other than that it is an IV. 


To avoid ECB encryption of very similar plaintext blocks in 
different packets, implementations MUST NOT use a counter or other 
low-Hamming distance source for IVs. 


The payload field, as defined in [ESP], is broken down according to 
the following diagram: 
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+ Initialization Vector (IV) + 
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Encrypted Payload (variable length) 
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3.1 Block Size and Padding 


The DES-CBC algorithm described in this document MUST use a block 
size of 8 octets (64 bits). 


When padding is required, it MUST be done according to the 
conventions specified in [ESP]. 


4. Key Material 


DES-CBC is a symmetric secret key algorithm. The key size is 64-bits. 
[It is commonly known as a 56-bit key as the key has 56 significant 
bits; the least significant bit in every byte is the parity bit.] 


[arch] describes the general mechanism to derive keying material for 
the ESP transform. The derivation of the key from some amount of 
keying material does not differ between the manually- and 
automatically-keyed security associations. 


This mechanism MUST derive a 64-bit key value for use by this cipher. 
The mechanism will derive raw key values, the derivation process 


itself is not responsible for handling parity or weak key checks. 


Weak key checks SHOULD be performed. If such a key is found, the key 
SHOULD be rejected and a new SA requested. 


Implementation note: 
If an implementation chooses to do weak key checking, it should 
recognize that the known weak keys [FIPS74] have been adjusted for 


parity. Otherwise the handling of parity is a local issue. 


A strong pseudo-random function MUST be used to generate the required 
key. For a discussion on this topic, reference [RFC1750]. 
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4.1 Weak Keys 


DES has 16 known weak keys, including so-called semi-weak keys. The 
list of weak keys can be found in [FIPS74]. 


4.2 Key Lifetime 


[Blaze96] discusses the costs and key recovery time for brute force 
attacks. It presents various combinations of total cost/time to 
recover a key/cost per key recovered for 40-bit and 56-bit DES keys, 
based on late 1995 estimates. 


While a brute force search of a 56-bit DES keyspace can be considered 
infeasable for the so-called casual hacker, who is simply using spare 
CPU cycles or other low-cost resources, it is within reach of someone 
willing to spend a bit more money. 


For example, for a cost of $300,000, a 56-bit DES key can be 
recovered in an average of 19 days using off-the-shelf technology and 
in only 3 hours using a custom developed chip. 


It should be noted that there are other attacks which can recover the 
key faster, that brute force attacks are considered the "worst case", 
although the easiest to implement. 


[Wiener94] also discusses a $1M machine which can break a DES key in 
3.5 hours (1993 estimates), using a known-plaintext attack. As 
discussed in the Security Considerations section, a known plaintext 
attack is reasonably likely. 


It should also be noted that over time, the total and average search 
costs as well as the average key recovery time will continue to drop. 


While the above does not provide specific recommendations for key 
lifetime, it does reinforce the point that for a given application 
the desired key lifetime is dependent upon the perceived threat (an 
educated guess as to the amount of resources available to the 
attacker) relative to the worth of the data to be protected. 


While there are no recommendations for volume-based lifetimes made 
here, it shoud be noted that given sufficient volume there is an 
increased probabilty that known plaintext can be accumulated. 


5. Interaction with Authentication Algorithms 


As of this writing, there are no known issues which preclude the use 
of the DES-CBC algorithm with any specific authentication algorithm. 
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6. Security Considerations 


[Much of this section was originally written by William Allen Simpson 
and Perry Metzger. ] 


Users need to understand that the quality of the security provided by 
this specification depends completely on the strength of the DES 
algorithm, the correctness of that algorithm’s implementation, the 
security of the Security Association management mechanism and its 
implementation, the strength of the key [CN94], and upon the 
correctness of the implementations in all of the participating nodes. 


[Bel195] and [Bel196] describe a cut and paste splicing attack which 
applies to all Cipher Block Chaining algorithms. This attack can be 
addressed with the use of an authentication mechanism. 


The use of the cipher mechanism without any corresponding 
authentication mechanism is strongly discouraged. This cipher can be 
used in an ESP transform that also includes authentication; it can 
also be used in an ESP transform that doesn’t include authentication 
provided there is an companion AH header. Refer to [ESP], [AH], 
[arch], and [road] for more details. 


When the default ESP padding is used, the padding bytes have a 
predictable value. They provide a small measure of tamper detection 
on their own block and the previous block in CBC mode. This makes it 
somewhat harder to perform splicing attacks, and avoids a possible 
covert channel. This small amount of known plaintext does not create 
any problems for modern ciphers. 


At the time of writing of this document, [BS93] demonstrated a 
differential cryptanalysis based chosen-plaintext attack requiring 
2°47 plaintext-ciphertext pairs, where the size of a pair is the size 
of a DES block (64 bits). [Matsui94] demonstrated a linear 
cryptanalysis based known-plaintext attack requiring only 2%43 
plaintext-ciphertext pairs. Although these attacks are not 
considered practical, they must be taken into account. 


More disturbingly, [Wiener94] has shown the design of a DES cracking 
machine costing $1 Million that can crack one key every 3.5 hours. 
This is an extremely practical attack. 


One or two blocks of known plaintext suffice to recover a DES key. 
Because IP datagrams typically begin with a block of known and/or 
guessable header text, frequent key changes will not protect against 
this attack. 
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It is suggested that DES is not a good encryption algorithm for the 
protection of even moderate value information in the face of such 
equipment. Triple DES is probably a better choice for such purposes. 


However, despite these potential risks, the level of privacy provided 
by use of ESP DES-CBC in the Internet environment is far greater than 
sending the datagram as cleartext. 


The case for using random values for IVs has been refined with the 
following summary provided by Steve Bellovin. Refer to [Bel197] for 
further information. 


"The problem arises if you use a counter as an IV, or some other 
source with a low Hamming distance between successive IVs, for 
encryption in CBC mode. In CBC mode, the "effective plaintext" 
for an encryption is the XOR of the actual plaintext and the 
ciphertext of the preceeding block. Normally, that’s a random 
value, which means that the effective plaintext is quite random. 
That’s good, because many blocks of actual plaintext don’t change 
very much from packet to packet, either. 


For the first block of plaintext, though, the IV takes the place 
of the previous block of ciphertext. If the IV doesn’t differ 
much from the previous IV, and the actual plaintext block doesn’t 
differ much from the previous packet’s, then the effective 
plaintext won’t differ much, either. This means that you have 
pairs of ciphertext blocks combined with plaintext blocks that 
differ in just a few bit positions. This can be a wedge for 
assorted cryptanalytic attacks." 


The discussion on IVs has been updated to require that an 
implementation not use a low-Hamming distance source for IVs. 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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